home *** CD-ROM | disk | FTP | other *** search
- The Minutes below should be considered a Rough Draft - 4/01/92 Megan
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by Gary Malkin
-
- RIP-V2 Working Group Minutes
-
- Status Update
-
-
-
- Chairperson Gary Scott Malkin / gmalkin@ftp.com
-
- Mailing List ietf-rip(-request)@ftp.com
-
- Date of Last meeting San Diego IETF / March 18, 1992
-
- Date of next meeting Boston IETF / July 1992
-
- Progress Settled on final packet format and new field
- definitions. Determined that no backwards
- compatibility issues exist. Made first pass
- at listing the objects needed in the MIB.
-
- Milestones:
- Boston Final review of RIP-II I-D and submission into
- the standards track. First review of RIP-II MIB.
-
- Washington Review of implementations. Final review of MIB.
-
- TBD Given successful implementation experience,
- advancement of RIP-II to Draft Standard. Submission
- of MIB into the standards track.
-
- TBD Final meeting to achieve closure on any pending
- issues.
-
-
-
- Agenda
-
- o Review of Working Group charter
-
- o Review of newest draft document
-
- o Discussion of backwards compatibility issues
-
- o Discussion of security issues
-
- o What needs to go into the MIB
-
-
- The charter was accepted unchanged.
-
- There were two changes to the packet format do to some confusion about
- the Routing Domain field. The RD field, as defined, is a per packet,
- user configurable parameter. It has, therefore, been moved into the
- Must Be Zero field in the RIP packet header. The RD field which was in
- the RIP entry has been renamed to the Route Tag. It is used to indicate
- that the route was learned from an external source. The exact use of this
- field is still under discussion; however, it has been determined that
- the contents of the RT field must be preserved when that route is
- propagated.
-
- The subsumption of routes, made necessary by the addition of the subnet
- masks is still under work. The issues accompanying supernetting were
- also discussed, but no final solutions were reached. We did determine
- that there should be no user controls for this, since this could lead
- to black holes if routers were dis-similarly configured. It was decided
- that supernetting could not be used in the presence of RIP-I routers.
-
- It should be explicitly mentioned that next hop is an advisory value.
- Next hop may also only be used for the directly connected network
- over which it was received.
-
- It was decided that addressless links would not be considered.
-
- We will need a new route type for MIB-II.
-
- It should be mentioned, if RFC 1058 does not, that split horizon
- does not apply to routes learned via routing protocols other than RIP.
-